Single Radio Voice Call Continuity (SR-VCC) has been standardized since release 8 in 3GPP TS 23.216 (version 9.3.0: Single Radio Voice Call Continuity (SRVCC); Stage 2) to provide continuity when a single radio capable User Equipment (UE) moves from E-UTRAN/HSPA (Evolved UMTS Terrestrial Radio Access Network/High Speed Packet Access) to UTRAN/GERAN (UMTS Terrestrial Radio Access Network/GSM EDGE Radio Access Network) while engaged in a voice call established over IP Multimedia Subsystem (IMS).
The SRVCC architecture has evolved since release 8, as a result of a study that has been performed in release 10 to enhance the performance of SRVCC from E-UTRAN/HSPA to UTRAN/GERAN in terms of voice break induced by the SRVCC handover procedure. The result of that study is documented in 3GPP TR 23.856 (version 10.0.0: Feasibility study of SR-VCC enhancements), and was introduced in the 3GPP release 10 specifications.
FIG. 1 and FIG. 2 describe the pre-release 10 Single Radio VCC solution, in the particular case of an SRVCC handover from E-UTRAN to GERAN without DTM support. A prerequisite is that the signalling for establishing the voice call over PS is routed through (or “anchored in”) an AS in the 1MS domain called the SCC AS.
The call flow in FIG. 1, which is an excerpt from 3GPP TS 23.216 version 9.1.0, is the uncoordinated execution of the following two procedures:                IMS-level session transfer, initiated in step S710, and        Completion of the radio-level handover preparation and handover execution (step S713 onward).        
In step S701, the UE sends a measurement report to E-UTRAN.
In step S702, based on UE measurement reports, the source E UTRAN decides to trigger an SRVCC handover to GERAN.
In step S703, the source E UTRAN sends Handover Required (SRVCC HO Indication) message to the source MME. The SRVCC HO indication indicates to the MME that target is only CS capable, hence this is a SRVCC handover operation only towards the CS domain.
In step S704, based on the QCI associated with the voice bearer (QCI 1) and the
SRVCC HO indication, the source MME splits the voice bearer from the non voice bearers and initiates the PS-CS handover procedure for the voice bearer only towards MSC Server.
In step S705, the MME sends a SRVCC PS to CS Request (STN-SR) message to the
MSC Server. The MME received STN-SR from the HSS as part of the subscription profile downloaded during the E UTRAN attach procedure.
In step S706, the MSC Server interworks the PS-CS handover request with a CS inter MSC handover request by sending a Prepare Handover Request message to the target MSC.
In step S707, target MSC performs resource allocation with the target BSS by exchanging Handover Request/Acknowledge messages.
In step S708, target MSC sends a Prepare Handover Response message to the MSC Server.
In step S709, circuit connection is established between the target MSC and the MGW associated with the MSC Server e.g. using ISUP IAM and ACM messages.
In step S710, MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP JAM (STN-SR) message or a SIP INVITE (STN-SR) message towards the IMS.
In step S711, during the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point.
In step S712, the source IMS access leg is released as per TS 23.237.
It has to be noted that steps S711 and S712 are independent of step S713.
In step S713, the MSC Server sends a SRVCC PS to CS Response message to the source MME.
In step S714, the source MME sends a Handover Command message to the source E-UTRAN. The message includes information about the voice component only.
In step S715, the source E-UTRAN sends a Handover from E-UTRAN Command message to the UE.
In step S716, the UE tunes to GERAN.
In step S717, Handover Detection at the target BSS occurs. The UE sends a Handover Complete message via the target BSS to the target MSC.
As part of the session transfer procedure, the remote end is informed in step S711 that it shall now send the speech media to a new connection/port, which is the one that is hosted at the MGW.
Steps S710, S711 and S712 of FIG. 1 are further detailed in FIG. 2.
In steps S801 and S802, the SRVCC procedure specified in TS 23.216 results in an INVITE (STN-SR, SDP-MGW) message to be sent to the SCC AS with an STN-SR indicating use of SRVCC procedures for Access Transfer to CS access. The SDP-MGW parameter contains media flow description at the MGW. Steps S801 and S802 correspond to step 710 in FIG. 1.
In steps S803 and S804, the SCC AS uses the STN-SR to determine that Access Transfer using SRVCC is requested. The SCC AS is able to identify the correct anchored session. The SCC AS proceeds with the Access Transfer of the active session with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure. Steps S803 and S804 correspond to step S711 in FIG. 1.
In step S805a, if the Gm reference point is retained upon PS handover procedure (which is typically the case when the target access is UTRAN), then:
In steps S805a-1 and S805a-2, the UE sends a Re-INVITE to the SCC AS via the PS access to update the remaining non-voice media flow(s) associated with the recently added active session. If the UE is using ICS capabilities, this Re-INVITE also adds Gm service control to the active session and the UE subsequently sends Re-INVITEs for any remaining inactive bi-directional speech sessions that are to be transferred.
In step S805a-3, the SCC AS processes the Re-INVITE(s) and updates the Remote Leg if needed. Step S805a has no corresponding step in FIG. 1, because FIG. 1 applies when the target access is GERAN with no DTM support, whereas step S805a would typically be performed when the target access is UTRAN.
In step S805b, if the Gm reference point is not retained upon PS handover procedure (which is typically the case where the target access is GERAN), or if there was no other non-voice media flow(s) in the IMS session than the voice which was transferred to the target access, then the Source Access Leg is released. Step S805b corresponds to step S712 in FIG. l.
One thing which is important to note is that the signalling related to session transfer goes all the way down to the remote end, which increases the delay before the remote end switches the downlink media flow towards the MGW, and therefore creates a long voice break, especially in the case where one or both of the users involved in the call is/are roaming.
Therefore, a study was conducted in release 10 to investigate how to enhance the performance of SRVCC from E-UTRAN/HSPA to UTRAN/GERAN. The study is documented in 3GPP TS 23.856 (version 10.0.0: Feasibility study of SR-VCC enhancements).
Several architectures have been proposed for achieving that goal. One of them was based on utilizing the MSC/MGW as an anchor point for all calls, even the ones established on the PS side. FIG. 2 and FIG. 3 illustrate the basic principles of that solution.
FIG. 3 shows an example of a mobile originating call establishment.
In step S101, the UE transmits an INVITE message to a Serving Call State Control Function (S-CSCF).
In step S102, the S-CSCF, in response to the reception of the INVITE message, uses service logic with iFC.
In steps S103 and S104, the INVITE message is exchanged between the S-CSCF and a Service Centralization and Continuity Application Server (SCC AS).
In step S105, the S-CSCF sends the INVITE message to a function of the MSC, called Visited Access Transfer Functionality (VATF), which will anchor the call.
In step S106, a Media Gateway (MGW) is allocated.
In steps S107 to S109, the VATF initiates a new INVITE message which is routed back to the SCC AS, and to the remote party UE-2.
FIG. 4 is a high level illustration of what happens at SRVCC handover.
In step S201, the MSC receives an indication from the radio access network (RAN), and, in response to this indication, it starts sending to the target RNS/BSS.
In step S202, the MSC releases the source SIP access leg, which is the leg which goes from the UE, to the SCC AS down to the MSC/VATF (established through steps S1 to S5 in FIG. 1).
FIG. 5 illustrates another example of an SRVCC handover.
In steps S301 and S302, when the MSC receives an indication from the RAN, it sends an INVITE to the SCC AS indicating that the voice flow should now be sent towards the MGW.
In step S303, the SCC AS updates the Media Resource Function (MRF), either indicating it to bi-cast to the old transport address and the transport address of the MGW, or simply to switch and send to the address of the MGW.
In steps S304 and S305, the SCC AS sends a 200 OK message to the IMS, via the S-CSCF.
Step S305 further comprises Operations S305a-1 and S305a-2 of sending a Re-INVITE message from the UE to the SCC AS, via the S-CSCF.
In case the MRF was instructed to bi-cast, that bi-casting is stopped either when an indicating is received that the UE has arrived on the target side (operation S305a-3) or when a timer expires (operation S305b-2).
Step S305 further comprises operation S305a-4 of updating remote leg and operation S305b-1 of releasing the source access leg.
Another alternative was finally selected for the specifications. It introduces two entities called ATCF and ATGW which act as anchor point for the signaling and the media respectively, and are located in the same network as the UE performing the SRVCC procedure. The ATCF controls the media resources of the ATGW.
While the call flow in FIG. 1 still applies in the case of the release 10 architecture, the IMS aspects of the SRVCC procedures now correspond to what is described in FIG. 6, which is an excerpt from 3GPP TS 23.237 version 10.4.1.
In step S1001, the UE, the RAN, the MME/SGSN and the MSC interact, as specified in TS 23.216.
The main difference between that flow and the flow of FIG. 2 is that the INVITE sent by the MSC server in step S1002 is sent to the ATCF instead of being sent to the SCC AS. The ATCF then reconfigures the ATGW in steps S1003 and S1004 so that the voice media from the remote end is sent towards the MGW, instead of being sent to the transport address of the UE on the source access. As shown in the figure, the remote end does therefore not see any difference between the situations before and after the SRVCC handover.
In the SRVCC specifications up to and including release 10, only the E-UTRAN/HSPA to UTRAN/GERAN direction is addressed. How to perform subsequent handovers in the reverse direction (“handback”) was studied at the time SRVCC was first introduced (in 3GPP release 8), and a solution was proposed in 3GPP TS 23.216 version 1.1.0: (Single Radio Voice Call Continuity (SRVCC); Stage 2). But it then got subsequently removed from the specification as it was not deemed satisfactory.
Technical report 3GPP TR 23.885 (version 0.2.0: Feasibility study of SR-VCC for UTRAN/GERAN to E-UTRAN/HSPA service continuity) has been initiated in 3GPP release 10 and is pursued in 3GPP release 11. It aims at studying how the network could handover a single radio capable UE from UTRAN/GERAN to E-UTRAN, referred to as reverse SRVCC to E-UTRAN/HSPA, or rSRVCC in the following.
FIG. 7 represents steps of a method for performing an rSRVCC procedure according to the solution disclosed in TR 23.885 which is imported from version 1.1.0 of TS 23.216, in the particular case of handover from UTRAN or GERAN with Packet Switched (PS) handover support to E-UTRAN. It is based on the SRVCC pre-release 10 architecture.
That method can be decomposed in three parts: a handover preparation, a handover execution, and a voice re-establishment. A prerequisite is that the signalling for establishing the voice call over CS is routed (or “anchored”) through the SCC AS.
Handover preparation part comprises steps S1 to S7.
In step S1, a source Radio Network Subsystem (RNS) decides to trigger a handover to E-UTRAN based on UE measurement reports.
In step S2, the source RNS initiates PS relocation.
Step S2 comprises an operation S2a of sending, from the source RNS, a Relocation Required (including a Source to Target Transparent Container) message to a source Serving GPRS Support Node (SGSN).
Step S2 comprises an operation S2b of sending, from the source SGSN, a Forward Relocation Request message to a target Mobility Management Entity (MME) including information about the non-voice component only.
In step S3, the source RNS initiates Circuit Switched (CS) relocation. Step S3 is performed in parallel to step S2.
Step S3 comprises an operation S3a of sending, from the source RNS, a Relocation Required (including the same Source to Target Transparent Container as in step S2a) message to the source Mobile Switching Centre (MSC).
Step S3 comprises an operation S3b of sending, from source MSC, a Prepare Subsequent HO Request to the MSC server.
Step S3 comprises an operation S3c of sending, from the MSC server, a Forward Relocation Request (Source to Target Transparent Container) message to the target MME.
In step S4, the target MME synchronises the two Forward Relocation Request messages and requests resource allocation for the non-voice component only by exchanging Handover Request/Acknowledge messages with the target E-UTRAN.
In step S5, the target MME acknowledges the prepared CS relocation towards the source access.
Step S5 comprises an operation S5a of sending, from the target MME, a Forward Relocation Response (including a Target to Source Transparent Container) message to the MSC Server.
Step S5 comprises an operation S5b of sending, from the MSC Server, a Prepare Subsequent HO Response to the source MSC.
Step S5 comprises an operation S5c of sending, from the source MSC, a Relocation Required Acknowledge (Target to Source Transparent Container) message to the source RNS.
In step S6, the target MME acknowledges the prepared PS relocation towards the source access. Step S6 is performed in parallel to step S5.
Step S6 comprises an operation S6a of sending, from the target MME, a Forward Relocation Response (including the same Target to Source Transparent Container as in step S5a) message to the source SGSN.
Step S6 comprises an operation S6b of sending, from the source SGSN, a Relocation Required Acknowledge (Target to Source Transparent Container) message to the source RNS.
In step S7, the source RNS synchronises the two Relocation Required Acknowledge messages and sends a Handover from UTRAN Command message to the UE.
From step S1 to step S7, the UE is on the source access side. The MSC and the SGSN interact with the MME. As no bearer is established for voice on the PS side (i.e. in the PGW-SGW) at this point, the MME only requests from the eNodeB radio resources for the existing PS bearers. The eNodeB allocates the proper radio resources, builds a RRC message (“RRC reconfiguration message”), which is then transported into the Target to Source transparent container from the eNodeB to the RNS on the source side via the MME and the MSC/SGSN.
Handover execution part comprises steps S8 to S11.
In step S8, UE re-tunes to E-UTRAN radio and sends a Handover to E-UTRAN Complete message to the E-UTRAN.
In step S9, the target E-UTRAN informs the target MME by sending a Handover Notify message.
In step S10, the target MME completes the CS relocation.
Step S10 comprises an operation S10a of sending, from the target MME, a Forward Relocation Complete message to the MSC Server. MSC Server acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the source MME.
Step S10 comprises an operation S10b of sending, from the MSC Server, a Handover Complete message to the source MSC.
In step S11, the target MME completes the PS relocation. Step S11 is performed in parallel to step S10.
Step S11 comprises an operation S11a of exchanging, between the target MME and the source SGSN, Forward Relocation Complete/Acknowledge messages.
Step S11 further comprises an operation S11b of performing, at the target MME, the Modify bearer procedure with the Serving Gateway and the Packet Data Network Gateway (PDN GW). At this point the relocation of all non-voice PS hearers is completed and the user data are flowing across E-UTRAN access in both directions.
From step S8 onwards, the UE is on the target side. When it retunes to the target side, no bearer for voice exists. The voice call is therefore interrupted from that point on.
Voice re-establishment part comprises steps S12 to S15.
In step S12, UE performs a Tracking Area Update (TAU) procedure if required, e.g. due to UE mobility under UTRAN/GERAN coverage.
Subsequently, in step S13, UE initiates the Session Transfer procedure e.g. by sending a SIP INVITE (STI) message to the SCC AS. Standard IMS Service Continuity procedures are applied for execution of the Session Transfer, as described in 3GPP TS 23.237 (version 9.4.0: IP Multimedia Subsystem (IMS) Service Continuity; Stage 2). When receiving the INVITE from the UE, the SCC AS correlates it with the correct voice call, and initiates the update of the remote end with the Session Description Protocol (SDP) of this new EMS access leg. The downlink flow of VoIP packets is switched towards the PDN GW at this point.
In step S14, the IMS triggers a network-initiated dedicated bearer for the voice component.
In step S15, the IMS releases the CS access leg which result in release of resources in the MSC Server.
Voice can finally resume after step S15.
The main issue with this method is that it induces a long voice break at handover from UTRAN/GERAN to E-UTRAN/HSPA. A rough estimation would be that the break is of the order of a second, while the performance requirement set for the study is that the voice break should not exceed 300 ms.
Embodiments of the present invention aim at solving at least such issue. Namely, embodiments of the present invention will propose devices and methods for performing an rSRVCC procedure without inducing a long voice break at handover from GERAN/UTRAN to EISPA/E-UTRAN.